1960 年代初期，在 MIT 用電腦是這樣的：把程式打在一疊打孔卡上，交給操作員，排進隊伍裡，等前面的程式一個一個跑完。結果印出來，通常已經是隔天。程式裡有一個錯字，就得改好卡片，再排一次隊。
Fernando Corbató 覺得這種方式讓人火大。1961 年 11 月，他的團隊在 MIT 的 IBM 709 上展示了 CTSS，一套分時系統：一個監督程式在多個使用者之間快速切換，每個人坐在自己的終端機前，打一行指令，馬上看到回應，幾乎感覺不到在跟別人共用同一台機器。電腦從「交出去，明天再來拿」，變成了可以一來一往對話的東西。
六十多年後，用 agent 寫程式，有一部分又回到了交出去的模式。差別在於，現在的機器做到一半會停下來問問題，人在手機上就能回它。
Day 27 談的是讓 agent 在自己電腦的背景跑，這篇再往前一步：連電腦都不用開著，或者人根本不在電腦前。
Claude Code 有幾種「人不在電腦前」的用法，最容易搞混的是程式碼實際在哪裡執行。
雲端 session 跑在 Anthropic 管理的虛擬機器上，筆電闔上它照樣在跑。Remote Control 則相反，Claude Code 一直在自己的電腦上跑，手機和瀏覽器只是遙控器。GitHub 上的 @claude，跑在 GitHub 的 runner 上。選哪一個，取決於這個任務需要什麼：需要連公司內網的資料庫、用本機才有的工具，就只能在自己電腦上跑；只需要 repo 和套件，丟到雲端最省事。
從 claude.ai/code、Claude 手機 app 的 Code 分頁，或是終端機打 claude --cloud 加上一句任務描述，都能開一個雲端 session。Pro、Max、Team 方案，以及有對應席位的 Enterprise 使用者可以用，第一次打開 claude.ai/code 時，會引導授權 Claude 存取 GitHub 上的 repo。
有一個細節很容易踩到：雲端的虛擬機器 clone 的是 GitHub 上目前這條分支，不是本機的工作目錄。本機還沒 push 的 commit，雲端看不到，送出去之前先 push。
比較順的用法，是在本機先規劃、到雲端執行。官方文件建議的流程是：在本機用 plan mode 跟 Claude 討論做法，把定案的計畫存成 repo 裡的一個檔案，commit、push，再叫雲端照著那份計畫做，例如 claude --cloud "照 docs/plan.md 的計畫實作"。每一個 --cloud 都是獨立的 session，可以一次丟好幾個不相關的任務出去，各跑各的。
做完之後，在 claude.ai/code 上看 diff，可以直接在某一行留評論，跟下一則訊息一起送給 Claude，滿意了再開 PR。想接回本機繼續改，打 claude --teleport 選那個 session，它會把分支和整段對話一起拉下來。在外面想到要補一句，也不用找電腦打開網頁，任何登入同一個帳號的機器上，打 claude -p "補充的訊息" --cloud 再接上 session 的網址，就能把一句話塞進正在跑的 session；網址從 claude.ai/code 的 session 頁面直接複製即可。
Day 23 談過，每個人的 Claude Code 都會長成不一樣的雪花，雲端 session 正好會把這件事暴露出來。
雲端從一份全新的 clone 開始，只看得到 commit 進 repo 的東西。repo 裡的 CLAUDE.md、.claude 底下的 skills、agents 和 rules 都會帶過去；個人的 ~/.claude/CLAUDE.md、個人的 skills、用 claude mcp add 預設加在本機的 MCP server，則都不會。如果發現雲端的 Claude 不照團隊慣例做事，先檢查那條規則是不是只寫在自己的家目錄。MCP server 要用 --scope project 加，寫進 repo 的 .mcp.json 再 commit，雲端才載得到。
環境變數在 claude.ai/code 輸入框上方的雲端環境選單裡設定，點環境名稱旁的齒輪就能編輯。官方說明寫得很清楚：用這個環境的人都看得到這些值，不要把金鑰放進去。Pro 和 Max 方案有另一個選項叫 network secret，金鑰由代理在請求離開虛擬機器之後才加上去，session 裡的 Claude 看不到原本的值。
雲端 session 的網路預設是 Trusted 等級，只能連套件來源、GitHub 這類白名單上的網域。GitHub 的憑證不會進到虛擬機器裡，所有 git 操作都經過一個代理，由代理換上真正的 token。
這個代理會拒絕刪除分支、推送 tag，但官方文件也寫明，它不限制可以推到哪一條分支。Day 28 說過，推上遠端是真正的單向門。人不在旁邊的時候，這道門要在 GitHub 那一側關好：替主分支設好 branch protection 或 ruleset，要求一定要經過 PR 和 review 才能合併。雲端的 Claude 推得了自己的分支，推不進主線。
有些任務離不開自己的電腦，例如要連本機起的資料庫，或是要用公司內網才連得到的服務。這時候用 Remote Control。
已經在跑的 session，直接打 /remote-control，或是簡寫 /rc；要開新的，用 claude --remote-control 啟動。連上之後，再打一次 /remote-control 會打開狀態面板，裡面有網址和 QR code，手機一掃就在 Claude app 裡打開同一段對話，電腦和手機兩邊都能送訊息。官方說明，連線只會從本機向外發出 HTTPS 請求，不會在電腦上開任何對外的連接埠；連線期間的對話紀錄會存在 Anthropic 的伺服器上，好讓多個裝置同步。
搭配推播通知最好用。在 /config 裡打開 Push when actions required，Claude 停下來等權限確認或問問題時，手機就會跳出通知。實際的情境是這樣：下班前交代一個要跑很久的遷移任務，人在捷運上收到通知，看一眼它想執行的指令，按下同意，它繼續跑。
電腦上的 claude 程序一關，session 就離線了。筆電睡眠或斷網，恢復之後會自動重連；如果是透過 SSH 在遠端主機上跑，要放在 tmux 或 screen 裡，斷線才不會跟著結束。
也可以直接在 GitHub 上把事情交代給 Claude，連 Claude Code 的介面都不用開。
在 repo 裡打開 Claude Code，執行 /install-github-app，它會安裝 Claude 的 GitHub App、把認證存成 repo 的 secret，再準備好一個加入 workflow 檔案的 PR，合併之後就能用了。之後在 issue 或 PR 的留言裡寫 @claude，例如「@claude 照這個 issue 的描述實作」或「@claude 修掉 dashboard 的 TypeError」，Claude 會在 GitHub Actions 上執行，在同一個 issue 或 PR 回一則留言，隨著進度更新那則留言，需要時開 PR。只有對 repo 有寫入權限的人能觸發它，它也會讀 repo 裡的 CLAUDE.md。每次執行會同時花掉 GitHub Actions 的分鐘數和 token，在 workflow 裡用 claude_args 加上 --max-turns，可以限制它最多跑幾輪。
PR 開出去之後，CI 掛了、reviewer 留了意見，通常要等人回到電腦前才處理。本機切到 PR 的分支，在 Claude Code 裡打 /autofix-pr，Claude Code 會開一個雲端 session 盯著這個 PR：CI 失敗或有人留 review，它判斷修法明確就直接改、推上去；意見有歧義，就先回來問你。有一點要先確認：它在 GitHub 上的回覆會用你的帳號發出，如果 repo 有「看到留言就觸發部署」這類自動化，它的回覆也可能觸發，這種 repo 就不要開。
團隊和企業方案還有一個託管的 Code Review，由管理員開啟之後，PR 開出來就會有一組 agent 自動審查，把問題依嚴重程度標在對應的程式碼行上。它不會核准、也不會擋下 PR，只負責提出問題；每次審查平均 15 到 25 美元，另外計費。不想每個 PR 都跑，管理員可以在後台把 repo 的審查時機設成手動，需要時在 PR 留一句 @claude review。
CTSS 消掉的，是交出去之後只能乾等、出錯就再排一輪的那段空白。
現在把任務交給雲端或 GitHub，好像又回到了交出去的模式。批次年代留下來的習慣倒是值得帶著走。那時候一個錯字就要再等一輪，所以交出去之前，會先把卡片檢查清楚。現在對應的，是先在本機把計畫談定、把該 push 的 push 上去、把主分支的保護設好，再放心讓它自己跑。
延伸閱讀
iThome鐵人賽
看影片追技術